NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/563

Internet Message Format | 1996-08-05 | 5.3 KB

Path: cs.uwa.edu.au!jasonb
From: [e-mail] (Jason S Birch)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: 9 Jan 96 07:51:19 GMT
Organization: The University of Western Australia
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <4c9i2l$[e-mail]> <4ck47h$[e-mail]> <[e-mail]> <4cokkg$[e-mail]> <[e-mail]> <4cqrti$[e-mail]>
NNTP-Posting-Host: decadence.cs.uwa.oz.au
X-Newsreader: NN version 6.5.0 #3 (NOV)

[e-mail] (Stephan Schaem) writes:

> polymorphism?

> int a,b,c;

> ...
> a = b /c;
        ^
> a *= result;
    ^
The "/" and "*" are polymorphic - you can use them in any mathematical
expression, without caring whether the left and right sides are chars,
shorts, longs, floats, doubles, or any equivalent type. If they were
not polymorphic, you might have, for example:
a int= b int/ c;
a int*= result;

This is essentially what you have in assembler. Note that with C++,
you can overload "+", "-", "*", "/", "=", etc, to work with any custom
classes as well, so you could have, for example:

vector a,b,c;
real r;
...
a = b + c;
r = a * b;
cout << "Values are: " << a << ", " << r << ".\n";

and have, say:

Values are: [3,7,3], 67.

as the output.

> struct.float = a;

This is polymorphism of "=", but it's also taking advantage of the
fact that C can convert an integer into a float.

> I dunno , I just find it puzzling to declar variable without giving
> a care of what its usage will be. You programing practice is VERY unwise...

Your misunderstanding is that you think he means he has no idea of
what types each variable is, whereas what he's saying is he need have
no idea of how each type is actually implemented on a particular
machine/OS - all he has to do is know how those types are defined to
behave under ANSI C. In fact, if you want to write portable code, you
have to restrict your knowledge of behaviour of the types to that
which is guaranteed under ANSI C. Taking advantage of any other
information you might have (eg. endian-ness, number of bits) limits
your portability.

>: I know better than to declare a value as unsigned long when I'm
>: going to assign a clock_t to it.  And if I did, I'd lose the
>: fractional part of a floating-point clock_t, not the upper 32 bits.

> You said yourself after peeking at the .h that clock_t was a ulong.
> But you know better then not using a ulong... ? Should I assume
> you alway use the largest data type available,double ? (What a waist)

No, you should use clock_t! If you want a variable to use in functions
that expect a clock_t, you declare it thus:

clock_t Stephens_var;

You do *not* declare it as:

ulong Stephens_var;

even if you *know* that on your particular implementation, that's what
it really is, because that restricts your portability.

> And you mean you would loose the fractional part of clock_t if you
> used ulong , not the upper 32bits? This make absolutly no sense since
> we are talking about interger types.(BTW copy 0x00000001 into a 2byte int,
> you will loose the upper 16bit... )

You lose nothing if you declare it as clock_t.

> If the header file was programmed correctly it would not use ANSI data
> type directly....

Why not? You should just know better than to look at it and take
advantage of that information.

Incidentally, when I create a custom data type I want to keep private,
I provide a public header file similar to:

typedef void *MyDataType;

MyDataType *MDT_Create(...);
void MDT_Dispose(MyDataType *);

and inside the private header file, I actually define what MyDataType
is. This way, no-one can "accidentally" use the internal definition,
and I am free to change it at will, without having to worry about
those who *don't* know better than to look at it and take advantage of
the information.

> The way you get optimal speed is optimizing the optimal algorithim.
> If you stop at the algorithm you loose... Optimizing at this stage
> will give an exponential result on the work you done on the algorithm.
> And usually this stage is done in assembler.

The problem is, do you want portable code? If yes, then you should be
aware that what might be optimal for one particular CPU using one
particular compiler is not necessarily the same for another. For
example, scanning through an array and adding the contents using array
dereferencing and a moving pointer: On an 040 Amiga, the latter was
faster; using gcc on a Sun, both produced the same assembler code; and
using Metrowerks on a PowerMac, the former was actually quicker
because the pointer method used post-incrementing (ie. sum += *ptr++)
and the compiler wasn't smart enough to realize it didn't need to
store the pre-incremented value and used an extra register to store
it. The moral? Don't make assumptions about what is an optimization,
and what isn't, unless you test it on every combination you plan to
run it on.

> Stephan

--
Jason S Birch                        ,-_|\ email: [e-mail]
Department of Computer Science      /     \ Tel (work): [phone]
The University of Western Australia *_.-._/ Fax (work): [phone]
Nedlands  W. Australia  6907             v  Tel (home): [phone]